PATENT 

REMARKS 

Claims 1, 4-13, 29, 31-38, 48, 50-54, 60, and 62-66 are pending in the application. 
Claims 14-17, 19, 21-25, 27-28, 39, 40, 42, 44-47, 55-56, 67-68, and 70 have 
been canceled. 

Claims 1, 4-13, 29, 31-38, 48, 50-54, 60, and 62-66 have been rejected. 

Restriction Requirement 

The Examiner has required restriction to one of the following inventions under 35 
U.S.C. § 121: 

Group I. Claims 1, 4-13, 29, 31-38, 48, 50-54, 60, and 62-66, drawn to 
flow control of data transmission through a network, classified in class 
370, subclass 235. 

Group II. Claims 14-17, 39, 40, 42-47, 67-68, and 70 drawn to 
sequencing or resequencing of packets to insure proper output sequence 
order, classified in class 370, subclass 394. 

Group in. Claims 22-25 and 27-28, drawn to control of data admission to 
a network, classified in class 370, subclass 230. 

In response to the Examiner's restriction requirement, the Applicants hereby affirm the 
election, without traverse, to prosecute claims 1, 4-13, 29, 31-38, 48, 50-54, 60, and 62- 
66. 

Please cancel claims 14-17, 19, 21-25, 27-28, 39, 40, 42, 44-47, 55-56, 67-68, and 
70 without prejudice to the subject matter disclosed therein. 

Rejection of Claims under 35 U.S.C. $103(a) 
Claims 1, 4-5, 8-10, 13, 29, 32-33, 36-38, 48, 51-52, 60 and 64 stand rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Liu et al. (USPPN 2002/0146016) 
("Liu") in view of Chuah et al. (USPN 6,519,254) ("Chuah"). The Applicants 

respectfully traverse this rejection. 
Claim 1 recites: 
A network device comprising: 
an output port; 
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a control unit coupled to the output port; 

a queue configured to store a copy of a packet forwarded to the output port; and 

a memory coupled to the output port, 

wherein the output port is configured to output packets for transmission 

via a network tunnel, 

wherein the network tunnel aggregates a plurality of flows, 

wherein the memory is configured to store information, 

wherein the information identifies packets which have been forwarded via 

the network tunnel, and 

wherein the queue indicates how many packets in each of the flows are 

outstanding within the network tunnel. 

The rejection notes that Liu fails to teach a queue that indicates how many packets 

in each of the flows are outstanding within the network tunnel. Office Action, p. 7. 

Accordingly, the rejection relies solely on Chuah to teach this feature. 

Chuah describes a system in which a tunnel destination point (TDP) maps RSVP 

sessions to tunnels in a manner that provides the appropriate delay requirement for the 

RSVP sessions. Chuah, Abstract and col. 6, lines 1-25. The cited portions of Chuah state: 

Although the above-mentioned modified fonn of RSVP, which aggregates 
RSVP-based QoS requests, is a solution to the problem, such a modified 
form of RSVP is no longer purely receiver-oriented. Chuah, col. 1, lines 
66-67. 

The delay guarantee provided by a tunnel is a function of the burst size 
b.sup.T and bandwidth R.sup.T as shown in the above-mentioned article 

"Aggregating RSVP-based QoS Requests," by Guerin et al. Note that if a 
session needs a delay guarantee d, only when all the tunnels with delay 
guarantee less than d have been filled is it necessary to use a tunnel j with 
d.sub.j.sup.T >d. In other words, d.sub.j.sup.T should be adjusted so that 
d.sub.j,new.sup.T <d.sub.j,old.sup.T. TTiis implies that one either has to 
increase the bandwidth for an existing tunnel, or decrease the burst size 
permitted at a tunnel, with d.sup.T >d. In either case, a 
TUNNEL_FLOWSPEC is sent from the TDP to the TSP to announce the 
tunnel parameter change. Chuah, col. 10. lines 48-59. 

1. A method for use in packet communication systems utilizing a Resource 
Reservation Protocol (RSVP), the method comprising the steps of: 
creating an RSVP PATH message at a packet sender, said RSVP PATH 
message containing information on routing reservation-request messages 
from a packet receiver to the packet sender; sending said RSVP PATH 
message from the packet sender through a Tunnel Source Point (TSP) to 
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the packet receiver through a Tunnel Destination Point (TDP), wherein a 
plurality of RSVP tunnels that can each transport one or more packet 
flows exist between the TSP and the TDP; creating an RSVP RESV 
message at the packet receiver, said RSVP RESV message containing 
parameters for a proposed RSVP tunnel that would allow a set of 
aggregated individual packet flows to travel within a given Quality of 
Service (QoS) through said proposed RSVP tunnel; sending said RSVP 
RESV message from the packet receiver to the TDP; determining at the 
TDP an actual RSVP tunnel from the existing set of RSVP tunnels that is 
sufficient to satisfy the parameters contained within the RVSP RESV 
message; assigning said set of aggregated individual packet flows to said 
determined RSVP tunnel; creating a TUNNEL_BINDING object, said 
TUNNEL-BINDING object containing information on the assigned RSVP 
tunnel; sending the RVSP RESV message and the TUNNEL_BINDING 
object from the TDP to the TSP; sending the RVSP RESV message from 
the TSP to the packet sender; and using the assigned RSVP tunnel for said 
set of aggregated individual packet flows sent through the TSP. Chuah, 
claim 1. 

None of the above cited portions of Chuah provide any teaching with respect to 
indicating or otherwise tracking how many packets in each flow are outstanding within 
the network tunnel. Instead, the cited sections talk about how RSVP sessions are mapped 
to tunnels that satisfy the delay requirements of the sessions, and how if no suitable 
tunnels are available, the parameters (e.g., bandwidth or burst size) of a tunnel can be 
modified to make it a suitable tunnel. Furthermore, Chuah' s claim 1 indicates that it is an 
aggregated set of packet flows, not individual packet flows, that is assigned to the RSVP 



Nothing in the cited portions of Chuah teaches or suggests the act of indicating or 
a need to indicate the number of packets within each of the individual flows that are 
currently outstanding within the tunnel. Instead, the cited portions of Chuah merely 
disclose how an RSVP session, which appears to facilitate transmission of an aggregated 
set of individual packet flows, is mapped to a tunnel based upon the RSVP session's 
delay requirements and the tunnel's delay characteristics. 

Additionally, in Chuah' s system, it is the tunnel destination point, not the tunnel 
source point, that performs the mapping functions. Chuah, col. 4, lines 56-59. Thus, 
Chuah' s mapping is not performed by a device that contains an output port for 
transmission via a network tunnel; instead, Chuah' s mapping is performed by the device 
that receives packets from the network tunnel. As noted throughout Chuah, one of 
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Chuah's goals was to support a receiver-oriented RSVP type signaling. See e.g., Chuah, 
Abstract. Thus, Chuah's teachings do not appear to be applicable to a device such as that 
described in the cited portions of Liu and claim 1, which is coupled to output packets for 
transmission via a tunnel. Accordingly, it is not clear how Chuah's teachings could be 
combined with those of Liu. 

The rejection states that "tunnel bandwidth requirement per flow implicitly 
provides for the number of packets within each flow." Office Action, p. 7. However, this 
does not appear to be the case. Chuah's mappings and actions appear to be completely 
independent of how many packets within a given flow are currently outstanding in the 
tunnel (the RSVP session appears to be assigned to a tunnel before any packets are 
transmitted via that session, and thus no packets in that session could be outstanding 
within the tunnel), and there does not appear to be any reason to track such information. 
Chuah's determinations appear to be based on delay characteristics of a tunnel, not on the 
number of outstanding packets within the tunnel. Quite simply, nothing in the cited 
portions of Chuah teaches or suggests that the number of outstanding packets within a 
given flow is relevant to the operation of Chuah's system. Similarly, nothing in the cited 
portions of Chuah teach or suggest that any of the components within Chuah's system 
should or even could indicate the number of outstanding packets within a given flow. 

For at least the foregoing reasons, claim 1 is patentable over the cited art, as are 
its dependent claims 4-5, 8-10, and 13. Claims 29, 32-33, 36-38, 48, 51-52, 60 and 64 are 
patentable over the cited art for similar reasons. 

Claims 6-7 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Liu 
in view of Chuah as applied to Claim 1, and further in view of Le Gouriellec et al. 
(USPPN 2003/01 12756) ("Le Gouriellec"). The Applicants respectfully traverse this 
rejection for at least the reasons set forth above with respect to claim 1. 

Claims 11 and 12 stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Liu in view of Chuah as applied to Claim 1, and further in view of Bishard (USPPN 
2003/0165148) ("Bishard"). The Applicants respectfully traverse this rejection for at least 
the reasons set forth above with respect to claim 1. 

Claims 34, 35, 53, 54, 65, and 66 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Liu in view of Brewer et al. (USPPN 2006/0062233) ("Brewer"). The 
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Applicants respectfully traverse this rejection for reasons similar to at least the reasons 
set forth above with respect to claims 1, 29, 48, and 60. 

Claims 31, 50, 62 and 63 stand rejected under 35 U.S.C. §103(a) as being 
unpatentable over Liu in view of Bannister (USPN 6,145,032) ("Bannister"). The 
Applicants respectfully traverse this rejection for reasons similar to at least the reasons 
set forth above with respect to claims 1, 29, 48, and 60. 

CONCLUSION 

In view of the amendments and remarks set forth herein, the application and the 
claims therein are believed to be in condition for allowance without any further 
examination and a notice to that effect is solicited. Nonetheless, should any issues 
remain that might be subject to resolution through a telephone interview, the Examiner is 
invited to telephone the undersigned at 512-439-5087. 

If any extensions of time under 37 C.F.R. § 1.136(a) are required in order for this 
submission to be considered timely. Applicants hereby petition for such extensions. 
Applicants also hereby authorize that any fees due for such extensions or any other fee 
associated with this submission, as specified in 37 C.F.R. § 1.16 or § 1.17, be charged to 
Deposit Account 502306. 

Respectfully submitted, 

/Brenna A. Brock/ 

Brenna A. Brock 
Attorney for Applicants 
Reg. No. 48,509 
Telephone: (512) 439-5087 
Facsimile: (512)439-5099 
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